Hello, Just found out that DOORS 9.5.1.2 has introduced this bug. If you try to set default value to an attribute for a set of objects you get an error. Problem is that I have deployed it in my organization. I am looking for an alternatives: I know I can set a default value and life is good. But I have a user who needs the default value blank. I was wondering if there is a way to set a default value which is treated as blank. I tried null and <""> any thoughts?
Thanks jester76 - Tue Feb 25 12:10:16 EST 2014 | |||||||||||||||||||||
Re: DOORS 9.5.1.2 Default value error Why do you need to set a default value of blank? If you leave the default value unchecked, then the default value is blank. | |||||||||||||||||||||
Re: DOORS 9.5.1.2 Default value error GregM_dxler - Tue Feb 25 13:51:47 EST 2014 Why do you need to set a default value of blank? If you leave the default value unchecked, then the default value is blank. Correct, But if you try to reset the default value in that case on a set of selected objects or in current view. you get an error. | |||||||||||||||||||||
Re: DOORS 9.5.1.2 Default value error jester76 - Tue Feb 25 13:55:28 EST 2014 Correct, But if you try to reset the default value in that case on a set of selected objects or in current view. you get an error. Oh, this seems to be even more of an issue than first thought. I make a new attribute called Default Test. I then check the Default value and enter in Default Value as the Default value. Added the column for the new attribute and it shows up with Default Value for all objects. I then try and edit the Default Test attribute of one of the objects by double clicking the object's Default Value column. It will let me change the value, but won't let me remove the value. If I try to just delete the text, when I click out of the object, the default value comes back. Thinking that it has something to do with the object attribute having a default flag set or not, I tried to be sneaky by changing it's value (thereby making it not a default value) and then trying to delete the new value. Nope, when I go to delete the new value, it then jumps back to the default value again. If I go into the attribute property and uncheck the default value, all the objects will then have the default value removed. I don't see in the object properties, selecting the attribute and editing it, there is any way to select or unselect the default value. So the crux of the matter is that when a default value is checked for an attribute, it can have the default value or another value, but not blank. In order to get it empty, you have to have the default value unchecked. I then tried to use the attribute definition to determine properties and it gave me something interesting. I print out the canWrite boolean property and it gives true or false. I print out the inherit boolean property and it gives me true or false. But when I print out the defval boolean property it gives me 182631808 ! I have to assign it to a variable of the right type in order to get true/false. The only workaround I see is to never have a default value. Hope this helps a little, Greg
| |||||||||||||||||||||
Re: DOORS 9.5.1.2 Default value error GregM_dxler - Tue Feb 25 15:32:24 EST 2014 Oh, this seems to be even more of an issue than first thought. I make a new attribute called Default Test. I then check the Default value and enter in Default Value as the Default value. Added the column for the new attribute and it shows up with Default Value for all objects. I then try and edit the Default Test attribute of one of the objects by double clicking the object's Default Value column. It will let me change the value, but won't let me remove the value. If I try to just delete the text, when I click out of the object, the default value comes back. Thinking that it has something to do with the object attribute having a default flag set or not, I tried to be sneaky by changing it's value (thereby making it not a default value) and then trying to delete the new value. Nope, when I go to delete the new value, it then jumps back to the default value again. If I go into the attribute property and uncheck the default value, all the objects will then have the default value removed. I don't see in the object properties, selecting the attribute and editing it, there is any way to select or unselect the default value. So the crux of the matter is that when a default value is checked for an attribute, it can have the default value or another value, but not blank. In order to get it empty, you have to have the default value unchecked. I then tried to use the attribute definition to determine properties and it gave me something interesting. I print out the canWrite boolean property and it gives true or false. I print out the inherit boolean property and it gives me true or false. But when I print out the defval boolean property it gives me 182631808 ! I have to assign it to a variable of the right type in order to get true/false. The only workaround I see is to never have a default value. Hope this helps a little, Greg
I don't think the problems, which the two of you describe above are necessaryly the same. Jester76's problem produces an error message due to an action that should be quite common for regular users in several cases. This problem was already reported to IBM - however I don't remember when it was promised to be fixed. While the problem described by GregM_dxler from my point of view might perhaps not be a bug but wanted behaviour. @Jester76: Our solution was to create a script that iterates over the selected / viewed / all objects and changes the value back to default one by one. @GregM_dxler: Do you know if the behaviour you describe has been introduced only with DOORS 9.5.x? I think it was there all the time as in some of my scripts I use o.<attrName> = "" to set the attribute back to its default value. - Michael | |||||||||||||||||||||
Re: DOORS 9.5.1.2 Default value error MichaelGeorg - Wed Feb 26 07:48:27 EST 2014 I don't think the problems, which the two of you describe above are necessaryly the same. Jester76's problem produces an error message due to an action that should be quite common for regular users in several cases. This problem was already reported to IBM - however I don't remember when it was promised to be fixed. While the problem described by GregM_dxler from my point of view might perhaps not be a bug but wanted behaviour. @Jester76: Our solution was to create a script that iterates over the selected / viewed / all objects and changes the value back to default one by one. @GregM_dxler: Do you know if the behaviour you describe has been introduced only with DOORS 9.5.x? I think it was there all the time as in some of my scripts I use o.<attrName> = "" to set the attribute back to its default value. - Michael Hi Michael, Your right that the two problems are not exactly alike, but they are part of the same issue. In Jester76's case, when you try to set a default value of null, it gives you an error message saying the default value can not be empty. I can almost buy this as wanted behaviour, since it would make sense that if you want to specify a default value, then it should be a value. However, I think there is unexpected consequences with that, with the additional problems associated with the default value that I reported on. That is, having an attribute defined with a default value, and then not being able to set an object with no value. The bug is that if the attribute is defined as having a default value, then you can override that and set it to any other value EXCEPT no value. Not sure if this was introduced in 9.5.x or not. I have the same version as Jester76. I don't recall that this operated this way before though. As for the solution, it depends on what you wanted it to do. I can see it setting an object's attribute value to be the default value, or the same value as the default value. But if the attribute definition defines a default value, then I don't see how you can set an object's attribute to no value because instead it will set it to the default value. The only thing I can see is to set the attribute definition to not use a default value at all and then have the script set each object's attribute to that value. Then any other object that you want to set the attribute to no value, you can. Hope this is clearer, Greg | |||||||||||||||||||||
Re: DOORS 9.5.1.2 Default value error When an attribute definition has a "default" value, then when the value is otherwise null the value appears to be the default. "Appears" is most common uses, including:
No matter how you set the value to null or blank (in a column, in the properties, or with DXL), then it will appear to have the default value. That is not a "bug", that is the intended behavior. If the default value is "Default" and you type in the string "Default" for that obj-attr, it is hard to tell if it is defaulted or actual. The clumsy "hasSpecificValue()" perm can indeed tell the difference; which can be demonstrated nicely if you insert the following code into a layout column.
I can think of no method of changing the behavior that a null value is the "trigger" to display the Default. Thus, attributes with a default cannot be null. I wonder though, if you could just enter a space instead; which to human eyes appears to be null. -Louie In my opinion, it is usually unreasonable for "string" or "text" or attributes to have a default value. Enumerated and Boolean are natural candidates (note that booleans default to "False"); and I can see where defaulting an integer to "-1" may make sense instead of the default-default of zero. I notice that when in-place editing, you see the "set to default" as an option; for enumerated attributes is just another "enumeration". I notice when modifying the value from the Object Properties, you see a separate "set to default" button; which indeed I didn't see the first couple times I fired it up just now. "Inherited" values behave as do Default. I think if an attribute is both "inherited" and "defaulted", then "inherited" takes precedance; meaning the default value is only used when this object and none of it's ancestors has an actual ..err.. specific value.
| |||||||||||||||||||||
Re: DOORS 9.5.1.2 Default value error llandale - Wed Feb 26 15:26:50 EST 2014 When an attribute definition has a "default" value, then when the value is otherwise null the value appears to be the default. "Appears" is most common uses, including:
No matter how you set the value to null or blank (in a column, in the properties, or with DXL), then it will appear to have the default value. That is not a "bug", that is the intended behavior. If the default value is "Default" and you type in the string "Default" for that obj-attr, it is hard to tell if it is defaulted or actual. The clumsy "hasSpecificValue()" perm can indeed tell the difference; which can be demonstrated nicely if you insert the following code into a layout column.
I can think of no method of changing the behavior that a null value is the "trigger" to display the Default. Thus, attributes with a default cannot be null. I wonder though, if you could just enter a space instead; which to human eyes appears to be null. -Louie In my opinion, it is usually unreasonable for "string" or "text" or attributes to have a default value. Enumerated and Boolean are natural candidates (note that booleans default to "False"); and I can see where defaulting an integer to "-1" may make sense instead of the default-default of zero. I notice that when in-place editing, you see the "set to default" as an option; for enumerated attributes is just another "enumeration". I notice when modifying the value from the Object Properties, you see a separate "set to default" button; which indeed I didn't see the first couple times I fired it up just now. "Inherited" values behave as do Default. I think if an attribute is both "inherited" and "defaulted", then "inherited" takes precedance; meaning the default value is only used when this object and none of it's ancestors has an actual ..err.. specific value.
As Louie has pointed out, the observed behaviour is not a bug\defect of DOORS but is intended - or maybe it was an accidental intention as some features sometimes turn out to be. W.r.t. best practice when using enumerated lists in any software application, the use of a blank option is considered to be confusing when a value is deemed to be mandatory or needs to be explicit. Does a blank mean that someone has overlooked entering an expected value? Does a blank mean that a value is considered to be not applicable? A blank value can trigger a number of potentially incorrect interpretations. So in most cases where a mandatory value is expected, it is wise to have a default value that is a non blank, and that a blank is not a selectable option at all. The classic default value is "To be Determind" (TBD). This explicitly represents that no decision has been made and can be easily filtered to hunt down how many decisions are still outstanding. Another option that should be in most enumerated lists is "Not Applicable" - this indicates that a decsion has been made and it was determined that a value was not applicable, at least that can also be filtered easily and challenged where necessary.
Paul Miller | |||||||||||||||||||||
Re: DOORS 9.5.1.2 Default value error PRM - Wed Feb 26 16:00:05 EST 2014 As Louie has pointed out, the observed behaviour is not a bug\defect of DOORS but is intended - or maybe it was an accidental intention as some features sometimes turn out to be. W.r.t. best practice when using enumerated lists in any software application, the use of a blank option is considered to be confusing when a value is deemed to be mandatory or needs to be explicit. Does a blank mean that someone has overlooked entering an expected value? Does a blank mean that a value is considered to be not applicable? A blank value can trigger a number of potentially incorrect interpretations. So in most cases where a mandatory value is expected, it is wise to have a default value that is a non blank, and that a blank is not a selectable option at all. The classic default value is "To be Determind" (TBD). This explicitly represents that no decision has been made and can be easily filtered to hunt down how many decisions are still outstanding. Another option that should be in most enumerated lists is "Not Applicable" - this indicates that a decsion has been made and it was determined that a value was not applicable, at least that can also be filtered easily and challenged where necessary.
Paul Miller I have the following minority counter opinion; which I agree is subjective and by no means compelling. I argue that while it is true that "TBD" is easy to understand, being able for a human to notice it is more important. If an attribute value "must" have a value, then I think it is better if no-action is seem as a blank than "TBD", as it is easier for human eyes, when viewing a mostly populated list, to see a blank faster than to see some illegal value like TBD. For example for attribute "Severity", I think the blanks in the 2nd column are easier to see than the TBD in the 1st. We can have our cake and eat it too, the 3rd column.
I thus tend to reserve "default values" for the "default case" not the "illegal case"; folks can set the value when this particular object needs it. The "default case" for attribute "Status" may be "New"; which I'd make the "default value". -Louie I note that both "TBD" and a blank are equally easy for a DXL script (in general, computers) to find and "understand", for example in order to report (or filter) on the illegal values. You may notice that all stoves (that sill have rotary analog controlls), "off" is always up. It is thus easy to tell at a glance if any of the burners are "on"; the one that is not "up" stands out when its neighbors are all "up". Noticing that is it "on" at all is by far more important (for safety reasons) than being able to tell "how much on" it is. Take a closer look if you need to know that. Randomly changing the orientation of "off" of the dials would result in technical correctness (yes, you can still understand each dial and the burners would get to the right temperature), but you will end up frequently burning your food and sometimes your entire house; in spite of being "correct". I say "Correct" is less important than "Good". Unfortunately, "Correct" is far easier to objectively "prove". | |||||||||||||||||||||
Re: DOORS 9.5.1.2 Default value error llandale - Fri Feb 28 12:37:33 EST 2014 I have the following minority counter opinion; which I agree is subjective and by no means compelling. I argue that while it is true that "TBD" is easy to understand, being able for a human to notice it is more important. If an attribute value "must" have a value, then I think it is better if no-action is seem as a blank than "TBD", as it is easier for human eyes, when viewing a mostly populated list, to see a blank faster than to see some illegal value like TBD. For example for attribute "Severity", I think the blanks in the 2nd column are easier to see than the TBD in the 1st. We can have our cake and eat it too, the 3rd column.
I thus tend to reserve "default values" for the "default case" not the "illegal case"; folks can set the value when this particular object needs it. The "default case" for attribute "Status" may be "New"; which I'd make the "default value". -Louie I note that both "TBD" and a blank are equally easy for a DXL script (in general, computers) to find and "understand", for example in order to report (or filter) on the illegal values. You may notice that all stoves (that sill have rotary analog controlls), "off" is always up. It is thus easy to tell at a glance if any of the burners are "on"; the one that is not "up" stands out when its neighbors are all "up". Noticing that is it "on" at all is by far more important (for safety reasons) than being able to tell "how much on" it is. Take a closer look if you need to know that. Randomly changing the orientation of "off" of the dials would result in technical correctness (yes, you can still understand each dial and the burners would get to the right temperature), but you will end up frequently burning your food and sometimes your entire house; in spite of being "correct". I say "Correct" is less important than "Good". Unfortunately, "Correct" is far easier to objectively "prove".
I agree about the point that a blank in an attribute cell is more visually obvious, but a blank is still ambigouos.
Because mangement has an obsession with knowing how much more requirements analysis work is waiting to be done and other stakeholders such as Testers need a clear direction with some decisions, there needs to be clear measurement delineation between pending decisions and decisions already made. When using scripts or filters or whatever to get metrics, a blank could be interpreted as being a pending decision or it could mean, well, many other things (not applicable, illegal value, not known, zero, null etc). I don't advocate this for every attribute, it's kind of useful for really important attributes, particularly those that are used to report back to management to help them sleep at night. It doesn't have to be a boring "TBD" as the default, it can an actual value as a starting point such as your example about a "Status" type attribute, just preferably something that is not a blank. It's not law, it's just advice.
Paul Miller | |||||||||||||||||||||
Re: DOORS 9.5.1.2 Default value error PRM - Fri Feb 28 17:28:26 EST 2014
I agree about the point that a blank in an attribute cell is more visually obvious, but a blank is still ambigouos.
Because mangement has an obsession with knowing how much more requirements analysis work is waiting to be done and other stakeholders such as Testers need a clear direction with some decisions, there needs to be clear measurement delineation between pending decisions and decisions already made. When using scripts or filters or whatever to get metrics, a blank could be interpreted as being a pending decision or it could mean, well, many other things (not applicable, illegal value, not known, zero, null etc). I don't advocate this for every attribute, it's kind of useful for really important attributes, particularly those that are used to report back to management to help them sleep at night. It doesn't have to be a boring "TBD" as the default, it can an actual value as a starting point such as your example about a "Status" type attribute, just preferably something that is not a blank. It's not law, it's just advice.
Paul Miller I agree a blank loses credibility unless you know the attribute must have a valid value; in my case above a blank could be understood to mean no Severity instead of "TBD" Severity since there is nothing about that attribute that suggests it is mandatory ..err.. must be set mindfully. Note that my "Status" example does not need to be set mindfully, so "New" is reasonable for the default. The "Both Ways" above seems to mitigate your valid consern. -Louie | |||||||||||||||||||||
Re: DOORS 9.5.1.2 Default value error llandale - Wed Mar 05 15:12:47 EST 2014 I agree a blank loses credibility unless you know the attribute must have a valid value; in my case above a blank could be understood to mean no Severity instead of "TBD" Severity since there is nothing about that attribute that suggests it is mandatory ..err.. must be set mindfully. Note that my "Status" example does not need to be set mindfully, so "New" is reasonable for the default. The "Both Ways" above seems to mitigate your valid consern. -Louie I use colours for the different values to get over the man-readability issues, so a typical enumeration might be
The red of NOT SET grabs the attention The grey of N/A allows you to visually pass over this entry All valid values are in default black. | |||||||||||||||||||||